Financial system
Web app, 2021-PresentRedefining finances management & administration for small & medium companies

Summary
How to make a tool that integrates into workflows, not the other way around?
I helped to shape the product by research at its early stages. I've been developing it by continuous testing, conducting workshops with users and stakeholders to make the tool fully customisable. Measurable results:
- 50% reduction in administrative task costs,
- Expedited HR and administration staff training,
- Saved time that would have been used to adapt to a new off-the-shelf system.
1. My role
I combined business analyst and UX researcher functions, presenting research results to the entire team, supporting UX/UI designers and developers, and influencing team priorities. Team: 1 PM, 2-8 backend developers, 2 frontend developers, 1 UX researcher/designer (me), 1 UX/UI designer.
Team: 1 PM, 2β8 backend developers, 2 frontend developers, 1 UX researcher/designer (me), 1 UX/UI designer.

2. The problem and business goals
The problem
Spreadsheets based finance and administration management became a burden when the company began to grow rapidly. Difficult to maintain, hard to mine data, tons of human errors, lots of inquiries to the company's financial and HR departments.
Business goals
- Replace the current tool while maintaining finance workflow,
- Provide the tool for administration departments and employees,
- Prepare the company for expected rapid growth,
- Declutter the current database, but keep data consistent, between the old and the new system,
- Prevent errors.
3. Research highlights
A selection of the three challenges showing my impact on the product and the team's work.
π Challenge 1: beta testing
How I found issues and shortcomings before the release of the software. Tracking the finances of the company (first client) was a huge responsibility that I had to face.
π Approach
Because the company was about to switch its entire financial system overnight, I had two main research questions:
- Is the new software's feature set complete compared to company's current tools?
- What can block or hinder the performance of the finance and administration teams?
So I needed to compare the workflow of both tools and discover new needs. In order to answer both of these questions quickly and efficiently, I conducted in person and remote moderated usability tests combined with structured in-depth interviews. The combination of both methods simplified the research logistics - it did not take up too much time for users and the company's c-level, and it made it easier for me to arrange meetings.
Then I invited the entire team to help me analyse the recorded tests, which reduced my bias and the time to deliver the results.
π Output
1. List of recommendations divided into 2 categories:
- bugs to be fixed by dev team alone,
- design required β usability issues, previously unidentified needs.
The distinction allowed the team to work uninterrupted - while the dev team was fixing bugs, the UX team (including me) could focus on design and in-depth discovery of missing functionalities of the product.
2. A complete list of 45 prioritised issues in an easy-to-follow table. I linked the table to our GitHub repository, which helped me and the PM organise further work of the developers.

π Research impact
Example insights:
- Too late and incomplete validation when signing the contract extends and hinders the process (usability),
- List of features is complete for 1.0, but [Costs] lack certain billing information (undiscovered needs).
Example solution
An interface change (prompted by an insight) that made huge UX improvement and technical one for backend developers. The change consisted of:
- preview of the contract print version to reduce validation errors by a better match between the system and reality,
- separation of employee data from his/her contracts so the tool becomes more useful for HR team and itβs easier for developers to manage permissions to individual admin groups in the app.
π Challenge 2: features for v1.1
After the successful deploy of version 1.0, a plan was needed for further functionalities that would facilitate the work of the company's administration and the financial teams. My goal here was to discover ways to automate and speed up some of their tasks.
π Approach
I proposed in-depth interviews to learn as much as possible about the most repeated daily activities of the mentioned departments. I combined the interviews with contextual observation in the users' workplace, so I could see the workflow of a given user. I was also continouously gathering user feedback on a daily basis, so I could figure out what users wanted to do within the system. Together with UX/UI designer we came up with user flows and prototypes. I tested the prototypes with financial domain experts not only to find usability issues, but to make sure that new features would work in accordance with regulations and the ever-changing legislations.
π Output
- a list of new features prioritised according to their impact on the user's performance in everyday tasks,
- detailed description of the new features with use of user stories,
- user flows (block diagrams) for the most important features,
- tested prototypes (usability testing and expert interviews).
π Research impact
My research led to the successful transfer of complex business processes from spreadsheets to the new system.
π Challenge 3: new B2B settlement model
The task of UX/UI team was to design a solution that would enable project managers to maintain control over the fixed-price project profitability to keep the project aligned with the budget.
"Fixed price" was a new type of project settlement that we had to include in our web app. This is a case when the price for the project is determined in advance. Main goal of users was to count how much cost and time this project was consuming.
π Approach
I first had to find out how exactly the fixed-price model works to know what to ask people responsible for the company's budget. I used quick desk research and (again) interviews with people responsible for the company's budget and individual projects, during which I asked them to tell me about how they run fixed price projects from start to finish.
π Output
I summarised the collected data to the team and presented the functionality requirements. The presentation included design and frontend needs as well as backend requirements. The backend requirements written by the designer are not perfect, but with good team communication - it works!
Then I conducted a workshop based on the lighting decision jam method to plan our further work in detail and find potential pitfalls.
π Research impact
Development in progress - unfortunately we had to take a step back and first redesign another sections of the system to align it with new functionalities.
π Other challenges and continuous research
π¬ Communication with users and stakeholders
Shortly after the publication of version 1.0, several hundred users began to send ideas for improvements and report errors. New business goals started to come from stakeholders. I proposed, implemented and currently maintain: - public feedback board to report ideas and bugs, - a public roadmap of our product, which reduced the number of direct inquiries to our team, - communication of the product updates.
π Refining existing functionalities
In addition to the boards described above, I also used remote, unmoderated tests in Maze software to continuously improve the UX. I was able to design appropriate metrics and measure them using methods like surveys, card sorting, usability testing, and click heatmap analysis.
Refining features was also important from the perspective of ever-changing regulations of labor law or tax law, which was a challenge for me itself.